The invention relates to a semi-automatic method for testing program code, in particular graphical user interfaces (GUI), by means of a dedicated software tool, the program code defining a system under test (SUT) with a plurality of components and respective attributes.
The invention also relates to a software code for providing, when executed on a suitable computer device, a semi-automatic method for testing program code, in particular graphical user interfaces, by means of a dedicated software tool, which interacts with said program code during execution thereof.
The invention further relates to a testing system for semi-automatic testing of program code, in particular graphical user interfaces, by means of a dedicated software tool, the system further comprising a suitable computer device for executing said software code, said program code and a modified version of said program code.
The state of the art on automated graphical user interface (GUI) testing has two flavors: capture/replay and direct scripting in various forms and frameworks. Since the result of capturing is usually a script which then is replayed, both approaches essentially boil down to the same and are often combined.
The script contains user actions that should be simulated during script execution as a combination of the type of action (e.g. a click) and the action target (e.g. a button), where the target is identified from all available components using one or several of various identification criteria (such as a label, X/Y-coordinates, etc.).
After each action, the script may contain a number of checks or assertions, which are then executed and determine the correctness of the test result. Each of these checks also needs to identify the component the check is executed upon. This major problem is called component recognition or component identification.
The scripting approach has several drawbacks:                Even if a component is displayed only once on the GUI, it is often used in several tests. A single change to that component often means adapting many test scripts (and both actions and checks).        Frequent changes to the GUI cause a lot of additional effort to manually maintain the test scripts and lower confidence in the test result—as usually not the SUT is defect, but the test.        User actions have to be enhanced manually after recording to specify which attributes are used for identification of the target component and checks have to be defined manually to specify the expected value of one or several of such attributes. This causes a lot of additional effort.        